\section{PPU}
The PPU is modeled in a similar fashion to the CPU where we use a Reader 
monad transformer to hold the environment state containing references while 
letting ST be the innermost monad. 
\begin{code}
type PPU s a = ReaderT (PPUEnv s) (ST s) a
\end{code}
The environment is modeled as a Haskell data record containing the necessary 
shared registers defined as \texttt{ppuState} and memory layout where the memory is 
represented as STArrays. Finally some internal helper variables are defined 
for the helper functions. 
\begin{code}
data PPUEnv s = PPUEnv
    { ppuState      :: STRef s PPUState -- | PPU Registers

    -- | Memory layout.
    , patternTables :: Memory s -- | Address range: 0x0000 - 0x2000
    , nameTables    :: Memory s -- | Address range: 0x2000 - 0x3000
    , palettes      :: Memory s -- | Address range: 0x3F00 - 0x3F20
    , ppuOAM        :: Memory s -- | OAM (also known as SPR-RAM)

    -- | Internal variables of the PPU.
    , scanline      :: STRef s Int      -- | Current scanline
    , scanlineCycle :: STRef s Int      -- | Current clock cycle
    , sprAddr       :: STRef s Address  -- | SRAM Address
    , vLoopy        :: STRef s Address  -- | VRAM Address
    , tLoopy        :: STRef s Address  -- | Temporary VRAM Address
    , xLoopy        :: STRef s Address  -- | X-scroll
    , pixels        :: STRef s [Pixel]  -- | Generated pixels
    , firstWrite    :: STRef s Bool     -- | First write to SCROLL/ADDRESS

    -- | Actions used for synchronization.
    , ppuActions    :: STRef s [Action] -- | Actions perfomed
   }
\end{code}

As mentioned previously, when the CPU reads or writes to and from certain 
registers it will affect different parts of the internal PPU registers. 
This is handled by the \textit{action decoder} explained in more detail in the 
synchronization section later. \\

To simplify the implementation of the PPU and by doing this also have a faster 
graphics back-end we based our emulation on a per-scanline approach. It may not 
be as precise as a per-pixel based solution since it doesn't allow updates of 
registers mid-scanline but it is sufficient for a majority of games since only a 
handful need such a precise timing.

For each clock cycle the CPU runs, the PPU runs three cycles. We wanted to control the 
number of cycles the PPU executed by using the number of cpu cycles it took to 
execute the last instruction multiplied with three as an argument to \textit{runPPU}. 
In addition to the above mentioned instruction cycle counter we have to manage 
a \textit{ppu cycle counter} (pcc) since it takes the PPU 341 cycles to generate a scanline 
worth of pixels. Generating the pixels in a scanline is handled by the \textit{runScanline} 
function that basically maps the current scanline to the correct PPU phase. 
As explained in the PPU details section a scanline consists of 5 phases: 
initialization, rendering, cleanup, idle and v-blank.

\begin{code}
runPPU :: Int -> Int -> PPU s [Pixel]
runPPU _ 0  = return []
runPPU pcc cycles
    | pcc == 341 = do
        xs  <- runScanline           -- xs  :: [Pixel]
        xss <- runPPU 0 (cycles - 1) -- xss :: [Pixel]
        return (xs ++ xss)
    | otherwise = do
        runPPU (pcc + 1) (cycles - 1)
\end{code}

When \textit{runScanline} is in the phase of rendering pixels it will call the 
\textit{genBackground} function that will generate a whole scanline worth of 
pixels from the current row of 32 tiles. To achieve this it will combine color 
data from the \textit{pattern tables} with the \textit{attribute tables} to 
produce a color offset. \cite{loopyppu}
This offset is then used to index into a table mapping NES colors to RGB values 
to be outputted to the screen.

